DESCRIPTION 

DISPLAY PROCESSING DEVICE 



Technical Field 

[0001] The present invention relates to a display processing 
device that downloads an application program and displays an image 
based on that application program. 

Background Art 

[0002] In the past, a display processing device that downloads an 
application program (hereafter, simply "application") and displays 
an image based on that application has been provided, a 
representative example being a digital television terminal. 
[0003] Technology regarding such a display processing device, 
which downloads an application and executes the application, is 
prescribed in Non-Patent Reference 1 (the DVB-MHP standard 
(ETSITS 101812 DVB-MHP specifications V 1.0.2), which is the 
European digital television standard), Non-Patent References 2 and 
3 (the Home Audio Video Interoperability (HAVi) standard, which is 
a standard for digital consumer A/V appliances), and so on, and is 
publicly-known technology. The DVB-MHP standard employs the 
AWT and the 3ava Media Framework (JMF), which are Java (R) class 
libraries, and the HAVi Level 2 GUI, as defined in the HAVi standard. 
In addition, the DVB-MHP standard prescribes an Application 
Program Interface (API), and through this API, a downloaded 
application can control a display processing device that includes an 
On-Screen Display (OSD) plane, a video plane, and a still plane. 
For details, refer to the DVB-MHP specifications and chapter 8 of the 
HAVi specifications. 

[0004] Hereafter, a general overview shall be given regarding a 
display processing device used in the DVB-MHP standard. 

FIG. 1 is a conceptual diagram showing a downloaded 



application 2410 and a display processing device 2420. 
[0005] The display processing device 2420 is configured of an 
OSD control unit 2421, an OSD plane 2422, a video control unit 2431, 
a video plane 2432, a still control unit 2441, a still plane 2442, and 
5 a display 2450. 

[0006] The OSD control unit 2421 is configured of software and 
provides an API so that the downloaded application 2410 can render 
graphics. Through this API, the OSD control unit 2421, which has 
been instructed to render graphics, renders the graphics, resulting 
10 in the generated rendered image being stored in the OSD plane 
2422. 

[0007] The OSD plane 2422 is configured of a memory or the like, 
and stores the rendered Image generated by the OSD 2421. 
[0008] The video control unit 2431 Is configured of software and 

15 provides an API so that the downloaded application 2410 can 
reproduce video. Through this API, the video control unit 2431, 
which has been instructed to reproduce video, reproduces the video, 
and stores the reproduced video In the video plane 2432. Decoding 
a video signal sent as an MPEG-2 and converting it into a displayabte 

20 format can be given as a specific example of video reproduction. 
[0009] The video plane 2432 is configured of a memory or the like, 
and stores the video reproduced by the video control unit 2431. 
[0010] The still control unit 2441 is configured of software and 
provides an API so that the downloaded application 2410 can render 

25 a background image. Through this API, the still control unit 2441, 
which has been Instructed to render a background image, renders 
the background image, and stores the generated background Image 
in the still plane 2442. Decoding of MPEG-I data and single-color 
filling can be given as specific examples of processing for rendering 

30 a background image. 

[0011] The still plane 2442 Is configured of a memory or the like, 
and stores the background image generated by the still control unit 
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2441. 

[0012] The display 2450 superimposes the image stored In the 
video plane 2432 on the image stored in the still plane 2442, and 
after that, further superimposes the Image stored in the OSD plane 
5 on the previous superimposed image; the display 2450 then displays 
a final synthesized image. 

[0013] FIG. 2 is a diagram showing each image synthesized by 
the display 2450 and the synthesized image that is ultimately 
displayed. Here, the images stored in the still plane 2442, the 
10 video plane 2432, and the OSD plane 2422 are synthesized and 
displayed. 

[0014] FIG. 2 (1) is an image stored in the OSD plane 2422. In 
FIG. 2 (1), the OSD plane 2422 stores an image that includes 
graphics content 2501, which shows a list of channels, and graphics 

15 content 2502, which shows TV program details. Note that in this 
image, information indicating transparency is stored in the areas 
aside from the graphics content 2501 and 2502. Here, "graphics 
content" refers to figures, characters, or the like that are rendered 
in the OSD plane through the downloaded application 2410 calling 

20 the API. 

[0015] FIG. 2 (2) is an image stored in the video plane 2432. In 
FIG. 2 (2), the video plane 2432 stores an image that includes video 
2503, which is reproduced at 1/4 the size of the screen in the 
upper-right corner of the screen. In this image, information 
25 indicating transparency is stored in the areas aside from the video 
2503. 

[0016] FIG. 2 (3) is an image stored In the still plane 2442. In 
FIG. 2 (3), the still plane 2442 stores a background 2504, which is 
filled with a single color, as an image. 
30 [0017] FIG. 2 (4) shows the result of the display 2450 
synthesizing the image stored in the OSD plane 2422 shown in FIG. 
2 (1), the image stored in the video plane 2432 shown In FIG. 2 (2), 
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and the image stored in the still plane 2442 shown in FIG. 2 (3). 
Specifically, the display 2450 superimposes the video 2503 stored in 
the video plane, as shown In FIG. 2 (2), on the background 2504 
stored in the still plane 2442, as shown in FIG. 2 (3); the display 
5 2450 then superimposes the graphics contents 2501 and 2502 
stored in the OSD plane 2422 shown In FIG. 2 (1), and displays the 
final Image. 

Non-Patent Reference 1: ETSITS 101812 DVB-IMHP Specifications 
10 vl.0.2 

Non-Patent Reference 2: HAVi vl.l, Chapter 8, May 15, 2001 
Non-Patent Reference 3: HAVi vl.l Java (R) 12 APIs, May 15, 2001 

Disclosure of Invention 

15 Problems that Invention is to Solve 

[0018] However, with the conventional display processing device, 
there is a problem in that graphics display performance is poor. 
[0019] In the conventional art, only one each of the OSD plane, 
video plane, and still plane are included, and thus it is impossible to 

20 improve the graphics display performance. For example, it is 
difficult to superimpose and display two kinds of animations. Note 
that the same applies to the video plane and the still plane. 
[0020] Accordingly, an object of the present invention, which has 
been conceived in light of the aforementioned problem, is to provide 

25 a display processing device with an improved graphics display 
performance. 

Means to Solve the Problems 

[0021] To solve the abovementioned problems, the display 
30 processing device according to the present invention is a display 
processing device which downloads a program and displays an 
image based on the downloaded program, and includes: a plurality 
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of graphics image storage units, eacli having an area for storing a 
graphics image; a first order storage unit which stores a first order 
assigned to the graphics image storage units; a notification unit 
which provides a notification regarding the first order stored in the 
5 first order storage unit; a program execution unit which stores 
graphics images in the graphics image storage units based on the 
first order notified by the notification unit, by executing the 
program; and a display unit that superimposes and displays the 
graphics images stored in the graphics image storage units 

10 according to the first order. 

[0022] In the case where two graphics images are synthesized 
and displayed, conventionally, the two graphics images are 
synthesized and stored in a single area within a singie plane 
(storage unit), and the synthesized image is displayed, through 

15 processing performed by a program. Therefore, the program must 
perform rendering taking into consideration the superlmposition of 
the two graphics images, which slows the processing speed of the 
program; in addition, it is difficult to develop a program that 
performs this kind of rendering processing. However, with the 

20 present invention as described above, processing by the program 
only requires storing the graphics images in each graphics image 
storage unit; thus it is possible to improve processing speed and 
increase graphics image display performance. Moreover, the 
program is notified of the first order, and therefore the program can 

25 store the appropriate graphics image in the appropriate graphics 
Image storage unit, thus making it possible to display a correct 
synthesized image in the display unit. For example, with animation, 
video game machines, and the like, it is possible to quickly and 
correctly synthesize and display a graphics image showing a fighter 

30 plane and a graphics image showing flames rising from a building 
attacked by the fighter plane; it is also possible to smoothly display 
continuous changes occurring in such synthesized images. Also, 
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since rendering processing tal<ing into consideration the 
superimposition of plural graphics Images is not necessary, the 
workload required to develop the program can be reduced. 
[0023] In addition, the notification unit may notify the 
5 program execution unit of the first order by arranging identification 
information for identifying each of the graphics image storage units 
in an array according to the first order stored in the first order 
storage unit, and pass the array to the program execution unit. For 
example, the first order storage unit may store a position of the 
10 graphics image storage unit within the first order, and the 
Identification Information, for each of the graphics image storage 
units. 

[0024] Through this, identification information arrayed in 
accordance with the first order is passed to the program execution 

15 unit, and therefore the program execution unit can easily know the 
first order assigned to the plural graphics image storage units 
through the array. It Is also possible to store the correct graphics 
image In each graphics image storage unit based on the first order. 
[0025] In addition, the display processing device may further 

20 Include a changing unit which changes the first order stored In the 
first order storage unit, and the notification unit may notify the 
program execution unit of the changed first order. For example, the 
changing unit may change the position of each graphics image 
storage unit stored in the first order storage unit. To be more 

25 specific, the changing unit may interchange the positions of two of 
the graphics image storage units stored in the first order storage 
unit. 

[0026] Through this, for example, when using a graphics 
image showing clouds, and a graphics image showing an airplane, it 
30 is possible to quickly and easily change the superimposition order of 
the graphics images, so as to show the airplane hidden within the 
clouds, the airplane in front of the clouds, and so on. 
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[0027] In addition, the display processing device may furtiier 
include a plurality of video image storage units, each having an area 
for storing a video image, and a second order storage unit which 
stores a second order assigned to the video image storage units. 
5 The notification unit may further notify the program execution unit 
of the second order stored in the second order storage unit; the 
program execution unit may further store video Images in each of 
the video image storage units based on the second order notified by 
the notification unit, by executing the program; and the display unit 

10 may superimpose and display the video images stored in the video 
image storage units according to the second order on the graphics 
images superimposed according to the first order. 
[0028] Through this, plural video Images are stored in each 
video image storage unit through the processing performed by the 

15 program, in the same manner as the abovementioned plural 
graphics images; therefore, processing by the program only 
requires storing the graphics images and the video Images in each 
graphics Image storage unit and each video Image storage unit 
respectively. Rendering processing taking into consideration the 

20 superimposition of each image is therefore unnecessary, and thus it 
is possible to Improve processing speed and Increase graphics Image 
and video image display performance. Moreover, the program is 
notified of the second order, and therefore the program can store the 
appropriate video image in the appropriate video image storage unit, 

25 thus making it possible to display a correct synthesized image in the 
display unit. For example, with a video game machine, it Is 
possible to quickly and correctly synthesize and render a graphics 
image showing a fighter plane, a graphics image showing flames 
rising from a building attacked by the fighter plane, and a video 

30 image of a user operating the video game machine; it is also 
possible to smoothly display continuous changes occurring in such 
synthesized Images. Also, since rendering processing taking into 
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consideration the superimposition of plurai graphics images and 
video images Is not necessary, the workload required to develop the 
program can be reduced. 

[0029] In addition, the display processing device may further 
5 include a plurality of still image storage units, each having an area 
for storing a still image, and a third order storage unit which stores 
a third order assigned to the still image storage units. The 
notification unit may further notify the program execution unit of the 
third order stored In the third order storage unit; the program 

10 execution unit may further store still images in each of the still 
image storage units based on the third order notified by the 
notification unit, by executing the program; and the display unit 
may superimpose and display the still images stored in the still 
image storage units according to the third order on the graphics 

15 Images and video images superimposed according to the first and 
second orders respectively. 

[0030] Through this, plural still images are stored in each still 
image storage unit through the processing performed by the 
program, in the same manner as the abovementioned plural 

20 graphics images; therefore, processing by the program only 
requires storing the graphics images, video Images, and still images 
in each graphics image storage unit, video image storage unit, and 
still image storage unit, respectively. Rendering processing taking 
into consideration the superimposition of each image therefore is 

25 unnecessary, and thus it is possible to improve processing speed and 
increase graphics image, video image, and still Image display 
performance. Moreover, the program is notified of the third order, 
and therefore the program can store the appropriate still image in 
the appropriate still image storage unit, thus making it possible to 

30 display a correct synthesized image in the display unit. For 
example, with a video game machine, it is possible to quickly and 
correctly synthesize and render a graphics image showing a fighter 



plane, a graphics image showing flames rising from a building 
attacked by the fighter plane, a video image of a user operating the 
video game machine, and a still image showing a bacl<ground behind 
the fighter plane; it is also possible to smoothly display continuous 
5 changes occurring in such synthesized images. Also, since 
rendering processing taking into consideration the superimposltion 
of plural graphics images, video images, and still images is not 
necessary, the workload required to develop the program can be 
reduced. 

10 [0031] In addition, the display processing device may further 
include a video image storage unit having an area for storing a video 
image, and a stifl image storage unit having an area for storing a still 
image. The first order storage unit may store the first order 
assigned to the graphics image storage units, the video image 

15 storage unit, and the still image storage unit; the program execution 
unit may store graphics images in each of the graphics image 
storage units, a video image in the video image storage unit, and a 
still image in the still image storage unit, based on the first order 
notified by the notification unit, by executing the program; and the 

20 display unit may superimpose and display the graphics images, the 
video image, and the still image stored in the graphics image 
storage units, the video image storage unit, and the still image 
storage unit respectively according to the first order. 
[0032] Through this, the video image and the still image are 

25 superimposed with plural graphics images and displayed, and thus it 
Is possible to expand the display details of the synthesized image 
displayed by the display unit. Moreover, the program is notified of 
the first order assigned to the plural graphics image storage units, 
the video image storage unit, and the stifl image storage unit; 

30 therefore, it is possible for the program to store the appropriate 
image in the appropriate storage unit and cause the display unit to 
display a correct synthesized image. 
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[0033] In addition, the display processing device nnay further 
Include a changing unit which changes the first order stored In the 
first order storage unit, and the notification unit may notify the 
program execution unit of the changed first order. For example, the 
5 changing unit may change the first order stored in the first order 
storage unit so that the graphics images sandwich at least one of the 
video image and the still image when the graphics Images, video 
image, and still image are superimposed. 

[0034] Through this, it is possible to quickly and easily change 
10 the superimposition order of each image. For example, images are 
superimposed and displayed so that a video image is sandwiched 
between two graphics images, thus improving the expandability of 
the display details. 

[0035] Note that the present invention can be realized not only 
15 as this kind of display processing device, but also as a method or 
program performed by the display processing device, as well as a 
storage medium which stores the program. 

Effects of the Invention 
20 [0036] The display processing device of the present invention has 
an advantageous effect In that It is possible to improve graphics 
display performance. 

Brief Description of Drawings 

25 [0037] FIG. 1 is a diagram showing a configuration of a 
conventional display processing device. 

FIG. 2 is a diagram showing plural images being synthesized. 
FIG. 3 is a block diagram showing a cable television system 
according to the first embodiment of the present invention. 
30 FIG. 4 is a diagram showing a configuration of a terminal 

apparatus according to the present invention, 

FIG. 5 is a diagram showing an example of the external 
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appearance of the terminal apparatus according to the first 
embodiment of the present invention. 

FIG. 6 is a diagram showing an example of the external 
appearance of a front panel according to the first embodiment of the 
5 present invention. 

FIG. 7 is a diagram showing a configuration of a program 
stored in the terminal apparatus according to the first embodiment 
of the present Invention. 

FIG. 8 is a schematic diagram showing a configuration of a 
10 display processing device and a downloaded program according to 
the first embodiment of the present invention. 

FIG. 9 is a diagram showing plural images being synthesized 
by the display processing device according to the first embodiment 
of the present invention. 
15 FIG. lOA is a diagram showing an example of a management 

table that is managed by a Z-order management unit according to 
the first embodiment of the present invention. 

FIG. lOB is a diagram showing an example of a management 
table that is managed by another Z-order management unit 
20 according to the first embodiment of the present invention. 

FIG. IOC is a diagram showing an example of a management 
table that is managed by yet another Z-order management unit 
according to the first embodiment of the present invention. 

FIG. 11 is a flowchart showing an operation of a Z order 
25 management unit according to the first embodiment of the present 
Invention. 

FIG. 12 is a flowchart showing an operation of another Z order 
management unit according to the first embodiment of the present 
invention. 

30 FIG. 13 is a flowchart showing an operation of yet another Z 

order management unit according to the first embodiment of the 
present invention. 



FIG. 14 is a diagram showing an example of application code 
according to the first embodiment of the present invention. 

FIG. 15 is a diagram showing rendering as carried out by the 
application according to the first embodiment of the present 
5 invention. 

FIG. 16 is a diagram showing another example of application 
code according to the first embodiment of the present invention. 

FIG. 17 is a diagram showing yet another example of 
application code according to the first embodiment of the present 
10 invention. 

FIG, 18 is a flowchart showing an operation of a Z-order 
changing unit according to the first embodiment of the present 
invention. 

FIG. 19 is a diagram showing a change in a management table 
15 according to the first embodiment of the present invention. 

FIG. 20A is a diagram showing two graphics images being 
superimposed in the first embodiment of the present invention. 

FIG. 20B is a diagram showing two graphics images being 
superimposed so that the vertical order is Inverted, in the first 
20 embodiment of the present invention. 

FIG. 21 is a diagram showing a method for changing the 
vertical order of areas in the first embodiment of the present 
invention. 

FIG. 22 is a diagram showing another method for changing 
25 the vertical order of areas in the first embodiment of the present 
Invention. 

FIG. 23 is a diagram showing another example of a 
management table that is managed by a Z-order management unit 
according to the first embodiment of the present invention. 
30 FIG. 24 is a schematic diagram showing a configuration of a 

display processing device and a downloaded program according to 
the second embodiment of the present invention. 
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FIG. 25 is a diagram showing an example of a management 
table that is managed by a Z-order management unit according to 
the second embodiment of the present invention. 
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25 

Best Mode for Carrying Out the Invention 
[0039] (First Embodiment) 

The embodiment of a cable television system in the present 

invention shall be explained with reference to the diagrams. 
30 [0040] FIG. 3 is a block diagram showing a relationship between 
apparatuses that make up a cable television system. This cable 
television system is configured of a head end 101 and three display 
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processing devices: a terminal apparatus Alll, a terminal 
apparatus B112, and a terminal apparatus C113. In the present 
embodiment, thiree terminal apparatuses are connected to one head 
end 101, but it is possible to implement the present invention even 
5 with an arbitrary number of terminal apparatuses being connected 
to the head end 101. 

[0041] The head end 101 transmits, to plural terminal 
apparatuses, broadcast signals such as video, audio and data, and 
receives data transmitted from the terminal apparatuses. 
10 [0042] The present invention relates mainly to the terminal 
apparatuses, and therefore detailed descriptions regarding the head 
end are omitted. 

[0043] The terminal apparatuses Alll, B112, and C113 each 
receive and reproduce broadcast signals transmitted from the head 
15 end 101. Furthermore, each terminal apparatus transmits data 
unique to each terminal apparatus to the head end 101. In the 
present embodiment, these three terminal apparatuses shall have 
the same configuration. 

[0044] FIG. 4 is a block diagram showing a hardware 
20 configuration of each terminal apparatus. A terminal apparatus 
200 Is configured of: a QAM demodulating unit 201, a QPSK 
demodulating unit 202, a QPSK modulating unit 203, a TS decoder 
205, an audio decoder 206, a speaker 207, a video decoder 208, a 
video plane 209, a still plane 210, an OSD plane 211, a display 212, 
25 a secondary storage unit 213, a primary storage unit 214, a ROM 
215, an input unit 216, and a CPU 217. In addition, a CableCard 
204 is attached to/detached from the terminal apparatus 200. 
[0045] FIG. 5 is a diagram showing an example of the external 
appearance of the terminal apparatus 200 configured as a flat-panel 
30 television. 

Aside from the CableCard 204, all of the constituent elements 
of the terminal apparatus 200 are built into a housing 301 of the 
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flat-screen television. 

[0046] The display 302 Is equivalent to the display 212 in FIG. 4. 

The front panel unit 303 is configured of plural buttons, and Is 
equivalent to the input unit 216 of FIG. 4. 
5 [0047] A signaiinput terminal 304 connects to a cable line to send 
signals to/receive signals from the head end 101. The signal input 
terminal 304 is connected to the QAM demodulation unit 201, the 
QPSK demodulation unit 202, and the QPSK modulation unit 203 
shown In FIG. 4. 

10 [0048] The CableCard 305 is equivalent to the CableCard 204 of 
FIG. 4. The CableCard 204 is embodied independently of the 
terminal apparatus 200 and can be attached to/detached from the 
terminal apparatus 200, as in the case of the CableCard 305 In FIG. 
5. The CableCard 204 shall be described in detail later. 

15 [0049] The CableCard 305 is inserted into an insertion slot 306. 

As shown in FIG. 4, the QAM demodulation unit 201 
demodulates a signal which has been QAM-modu!ated in and 
transmitted from the head end 101, according to tuning information 
that includes a frequency specified by the CPU 217, and passes the 

20 resultant to the CableCard 204. 

[0050] The QPSK demodulation unit 202 demodulates a signal 
which has been QPSK-moduiated In and transmitted from the head 
end 101, according to tuning information that includes a frequency 
specified by the CPU 217, and passes the resultant to the CableCard 

25 204. 

[0051] The QPSK modulation unit 203 QPSK-demodulates a signal 
passed from the CableCard 204, according to demodulation 
Information that includes a frequency specified by the CPU 217, and 
transmits the resultant to the head end 101. 
30 [0052] The CableCard 204 (305) is in a form that is attachable 
to/detachable from the main body of the terminal apparatus 200, as 
shown in FIG. 5. The connection interface between the main body 
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of the terminal 200 and the CabteCard 204 is defined In OpenCable 
(TM) HOST-POD (TM) Interface Specification 
(OC-SP-HOSTPOD-IF-I12-030210) and in specifications referred to 
by this specification. Here, those details are omitted. 
5 [0053] The TS decoder 205 performs filtering on the signal 
accepted from the CableCard 204, and passes necessary data to the 
audio decoder 206, the video decoder 208, and the CPU 217. Here, 
the signal sent from the CableCard 204 is an MPEG-2 transport 
stream. A detailed description of the MPEG-2 transport stream is 

10 given in the MPEG specification ISO/IEC 13818-1, and therefore 
detailed descriptions shall be omitted in the present embodiment. 
An MPEG2 transport stream is composed of plural fixed-length 
packets, and a packet ID is assigned to each packet. 
[0054] This process of extracting only necessary packets 

15 according to the packet IDs corresponds to the filtering performed 
by the TS decoder 205. The TS decoder 205 is capable of 
performing more than one filtering process simultaneously, at the 
instruction of the CPU 217. 

[0055] The audio decoder 206 concatenates audio data embedded 
20 in the packets in the MPEG-2 transport stream provided by the TS 
decoder 205, performs digital-analog conversion on the 
concatenated data, and outputs the resultant to the speaker 207. 
[0056] The speaker 207 performs the audio output of the signal 
provided by the audio decoder 206. 
25 The video decoder 208 concatenates video data embedded in 

the packets In the MPEG-2 transport stream provided by the TS 
decoder 205, performs digital-analog conversion on the 
concatenated data, thus generating a video image, and stores the 
resultant in the video plane 209. Here, the video decoder 208 can 
30 reproduce plural videos simultaneously and store the videos In the 
video plane 209. In addition, the video decoder 208 decodes 
MPEG-I data provided by the CPU 217, and stores the resultant in 
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the stiit plane 210. 

[0057] The video plane 209 is configured of a memory or the like, 
and stores the video image decoded by the video decoder 208. 
Here, the video plane 209 has plural storage areas. In the case 
5 where the video decoder 208 reproduces plural videos 
simultaneously, the decoded plural video images are each stored in 
storage areas within the video plane that correspond to each video 
image. 

[00583 The still plane 210 is configured of a memory or the like, 
10 and stores an MPEG-I image decoded by the video decoder 208, a 
still image rendered by the CPU 217, and so on. Images stored in 
the still plane 210 are primarily used as background images. Here, 
the still plane 210 has plural storage areas. 

[0059] The OSD plane 211 Is configured of a memory or the like, 
15 and stores a graphics image including graphics content rendered by 
the CPU 217, "Graphics content" refers to basic figures such as 
points, lines, and quadrangles; characters; and decoded image data 
as prescribed by the JPEG specifications, PNG specifications, and so 
on. Here, the OSD plane 211 has plural storage areas. 
20 [0060] The display 212 is configured of an image synthesis circuit 
and a Braun tube, a liquid crystal, or the like. The display 212 
synthesizes the images stored in the video plane 209, the still plane 
210, and the OSD plane 211, and outputs the resultant. 
[0061] The secondary storage unit 213, specifically configured of 
25 a flash memory or a hard disk and the like, stores and deletes data 
and programs specified by the CPU 217. Stored data and programs 
are referred to by the CPU 217. The stored data and programs are 
kept in storage even when power to the terminal apparatus 200 is 
cut off. 

30 [0062] The primary storage unit 214, specifically configured of 
RAM or the like, temporarily stores and deletes data and programs 
specified by the CPU 217. Stored data and programs are referred 
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to by the CPU 217. The stored data and programs are deleted when 
power to the terminal apparatus 200 is cut off. 
[0063] The ROM 215 is a read-only memory device. Specifically, 
the ROM 215 is configured of a Read-Only Memory (ROM), a 
5 Compact Disk Read-Only Memory (CD-ROM), a Digital Versatile Disk 
(DVD), or the like. The ROM 215 stores a program to be executed 
by the CPU 217. 

[0064] The input unit 216, specifically configured of a front panel 
or remote control, accepts an input from the user. 

10 [0065] FIG. 6 is diagram showing an example of the input unit 216 
configured as a front panel. A front panel 400 corresponds to the 
front pane! unit 303 shown in FIG. 5. The front panel 400 is 
configured of seven buttons: an up-cursor button 401, a 
down-cursor button 402, a left-cursor button 403, a right-cursor 

15 button 404, an OK button 405, a cancel button 406, and an ERG 
button 407. When the user presses a button, the CPU 217 is 
notified of the identifier of the pressed button. 
[0066] The CPU 217 executes the program stored in the ROM 215. 
In accordance with instructions from the executed program, the CPU 

20 217 controls the QAM demodulating unit 201, the QPSK 
demodulating unit 202, the QPSK modulating unit 203, the 
CableCard 204, the TS decoder 205, the video decoder 208, the 
display 212, the secondary storage unit 213, the primary storage 
unit 214, and the ROM 215. 

25 [0067] FIG. 7 is a conceptual diagram showing the program 
stored in the ROM 215 and executed by the CPU 217, and the 
downloaded application program (hereafter, simply "application") 
stored in the primary storage unit 214 and executed by the CPU 217. 
[0068] A program 500 is stored in the ROM 215, and is configured 

30 of plural subprograms. Specifically, the program 500 is configured 
of an OS 501, a Java (R) VM 502 ("VM 502", hereafter), a navigator 
503, a service manager 504, and a Java library 505 ("library 505", 
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hereafter). 

[0069] The OS 501 is a subprogram activated by the CPU 217 
when power to the terminal apparatus 200 is turned on. The OS 
501 stands for an operating system, an example of which is Linux or 
5 the like. The OS 501 Is a generic name for publicly known 
technology made up of a kerne! 501a for executing a subprogram in 
parallel with another subprogram and of a library 501b, and 
therefore a detailed description is omitted. In the present 
embodiment, the kernel 501a of the OS 501 executes the VM 502 as 

10 a subprogram. Meanwhile, the library 501b provides these 
subprograms with plural functions required for controlling the 
constituent elements of the terminal apparatus 200. 
[0070] A tuning function can be introduced as one example of the 
functions of the library 501b. With the tuning function, tuning 

15 information including a frequency is received from another 
subprogram and then passed over to the QAl^ demodulation unit 201. 
Accordingly, it is possible for the QAM demodulation unit 201 to 
perform demodulation based on the provided tuning information, 
and pass the demodulated data to the CableCard 204. As a result, 

20 the other subprograms can control the QAM demodulation unit 201 
via the library 501b. 

[0071] The VM 502 is a virtual machine which analyzes and 
executes programs written in the Java (R) language. Programs 
written in the Java language are compiled of intermediate code 

25 which does not depend on the hardware, called bytecode. The 
virtual machine is an interpreter which executes this bytecode. 
Some virtual machines translate the byte codes into an executable 
form which can be Interpreted by the CPU 217 and pass the resultant 
to the CPU 217, which executes it. The VM 502 Is prescribed by the 

30 program executed in the kerne! 501a, and started. In the present 
embodiment, the kerne! 501a specifies the navigator 503 as the 
program to be executed. Details of the Java language are 
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explained in many publications, such as "Java Language 
Specification" (ISBN 0-201-63451-1). Here, those details are 
omitted. In addition, detailed operations of the VM itself are 
explained in many publications, such as "Java Virtual Machine 
5 Specification" (ISBN 0-201-63451-X). Here, those details are also 
omitted. 

[0072] The navigator 503 is a Java program written In the Java 

language, and is started and sequentially executed by the VM 502. 
The navigator 503 performs such actions as displaying a channel list 
10 to the user, receiving, through the CPU 217, channel selection 
Instructions inputted by the user through the input unit 216, and 
selecting channels. 

[0073] The service manager 504 is a Java program written in the 
Java language which accepts the channel selection instructions from 

15 the navigator 503, and is sequentially executed by the VM 502. The 
service manager 504 selects the TV program of the channel specified 
by the user. Specifically, the service manager 504 downloads an 
application that controls the specified TV program, and performs 
processing up to starting the program. Processing following 

20 downloading of the application is carried out central to that 
application. Here, "downloading" refers to the process for 
extracting data such as the file system from packets in the MPEG-2 
transport stream and storing the extracted data into storage units 
such as the primary storage unit 214. 

25 [0074] Hereafter, a simple description of the procedure in which 
the service manager 504 downloads an application and starts the 
application shall be given. The details are of little relation to the 
present invention, and therefore shall be omitted, 
[0075] The service manager 504 first requests a Tuner 505c, 

30 present in the library 505, to perform tuning. The Tuner 505c 
refers to channel information stored in the secondary storage unit 
213 and obtains tuning information corresponding to the channel 
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selected by the user. Next, the service manager 504 requests a CA j 
505d present in the library 505 to perform descrambling. The CA | 
505d provides the CabieCard 204 with information required for 
descrambling through the library 501b in the OS 501. On the basis 
5 of such provided information, the CabieCard 204 descrambles the 
signal provided by the QAM demodulation unit 201, and passes the 
resultant signal to the TS decoder 205. Next, the service manager 

504 requests the AM 505b, which is present in the library 505, to 
execute the application provided by the specified channel. The AM 

10 505b fetches an Application Information Table (AIT) included in the 
channel, and fetches information concerning the application 
included in the channel. The AIT is prescribed in the DVB-MHP 
specifications. In accordance with the fetched information 
concerning the application, the AM 505b requests a DSMCC 505a 

15 located within the library 505 to download a file system made up of 
directories and files held by the specified channel. The DSMCC 
format, as denoted in the MPEG specification ISO/IEC 13818-6, is 
used as a method for embedding data such as the file system into, 
and fetching such data from, the MPEG-2 transport stream. The AM 

20 505b executes the application to be executed from the information 
contained in the file system downloaded to the primary storage unit 
214. In FIG. 7, the selected application is indicated as the 
downloaded application 506. 

[0076] The library 505 is a collection of plural Java libraries stored 
25 in the ROM 215. The library 505 provides a Java API for 
applications so that the applications can utilize the functions of the 
terminal apparatus 200. In the present embodiment, the library 

505 includes the DSMCC 505a, the AM 505b, the Tuner 505c, a CA 
505d,aJMF505e, anAWT505f, andaHAViLevel2GUI 505g. Note 

30 that the HAVi Level 2 GUI 505g includes an OSD processing unit 
505h, a video processing unit 505i, and a still processing unit 505j. 
[0077] The DSMCC 505a provides a function for controlling the TS 
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decoder 205 via the library 501b, fetching a file system multiplexed 
within the MPEG-2 transport stream in the DSMCC object carousel 
format, and storing the file system in the primary storage unit 214. 
The DSMCC object carousel format is prescribed in the MPEG 
5 specifications ISO/IEC 13818-6, and therefore detailed descriptions 
shall be omitted here. 

[0078] The AM 505b controls the TS decoder 205 via the library 
501b, fetching the Application Information Table (AIT) multiplexed 
within the MPEG-2 transport stream, and fetching the information 

10 concerning the application included in the channel. The AIT is 
prescribed in the DVB-MHP specifications. In accordance with the 
fetched information concerning the application, the AM 505b 
requests the DSMCC 505a, which is within the library 505, to 
download the file system, made up of directories and files, that the 

15 specified channel holds. The AM 505b starts the application 
specified by the AIT to be executed from the file system downloaded 
to the primary storage unit 214. 

[0079] The Tuner 505c controls the QAM demodulation unit 201 
via the library 501b, providing the function for tuning to the 

20 specified frequency. 

[0080] By providing the CableCard 204 with information 
necessary for decoding via the library 501b of the OS 501, the CA 
505d provides a function with which the CableCard 204 can 
descramble a scrambled MPEG-2 transport stream. 

25 [0081] The JMF 505e controls the TS decoder 205, the audio 
decoder 206, and the video decoder 208 via the library 501b, 
reproducing the audio and video. 

[0082] The AWT 505f provides a Java API through which the 
application performs rendering and which is used in accepting a key 
30 input notification from the input unit 216. The AWT 505f provides 
an API for rendering basic figures such as lines, points, and 
quadrangles, an API for decoding images in the Joint Photographic 
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Experts Group (JPEG) format or the Joint Photographic Experts 
Group (PNG) format and expanding those images in the OSD plane 
211. SpecificaMy, the AWF 505f is equivalent to the java.awt 
package, java.awt. event package, and other java.awt subpackages, 
5 as prescribed in The Java (R) Class Libraries, Second Edition, 
Volume 2 (ISBN 0-201-31003-1). Here, those details are omitted. 
[0083] The HAVi Level 2 GUI 505g provides an API so that the 
application can control the video plane 209, the still plane 210, and 
the OSD plane 211, and is configured of an OSD processing unit 

10 505h, a video processing unit 5051, and a still processing unit 505j. 
Specifically, each of these processing units are equivalent to the 
org.havi.ul package and the org. havi.ui. event package prescribed In 
the DVB-MHP specifications. Here, functions related to the present 
invention shall be described. 

15 [0084] The OSD processing unit 505h provides an API for 
controlling the OSD plane 211. Specifically, the OSD processing 
unit 505h is configured of the org. havi.ui. event package 
HGraphicsDevice and related classes. 

[0085] The video processing unit 5051 provides an API for 
20 controlling the video plane 209. Specifically, the video processing 
unit 505i is configured of the org. havi.ui. event package 
HVideoDevice and related classes. 

[0086] The still processing unit 505j provides an API for 
controlling the still plane 210, Specifically, the still processing unit 
25 505j is configured of the org. havi.ui. event package 
HBackgroundDevice and related classes. 

[0087] The downloaded application 506 is a Java program written 
in the Java language, and is sequentially executed by the VM 502. 

The application 506 includes display processing denotations for 
30 expressing a TV program in the terminal apparatus 200. 
Specifically, denotations such as the following are included: 
graphics content display processing using the AWT 505f and the OSD 
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processing unit 505h; video content display processing using tiie 
JMF 505e and tlie video processing unit 505i; and background image 
display processing using the still processing unit 505j. 
[0088] Hereafter, descriptions shall be given regarding a display 
5 function, which is the primary function of the present invention. 

FIG. 8 is a conceptual diagram showing a relationship 
between hardware components and software components related to 
the display function in the terminal apparatus 200. In FIG. 8, 
components given the same numbers as in FIGS. 4 and 7 represent 

10 the same components as shown in FIGS. 4 and 7. Here, the OSD 
processing unit 505h includes a Z-order management unit 601 and a 
Z-order changing unit 602; the video processing unit 505i includes a 
Z-order management unit 611 and a Z-order changing unit 612; and 
the still processing unit 505j includes a Z-order management unit 

15 621 and a Z-order changing unit 622. Furthermore, the video plane 
209 has two areas, which are a first video area 651 and a second 
video area 652; the still plane 210 has one area, which is a first still 
area 661; and the OSD plane 211 has two areas, which are a first 
OSD area 671 and a second OSD area 672. Here, the OSD 

20 processing unit 505h, video processing unit 505i and still processing 
unit 505j are configured as software, but the present invention can 
be realized even with these three units configured as hardware. In 
addition, the video plane 209 is described as having two areas, the 
still plane 210 as having one area, and the OSD plane 211 as having 

25 two areas; however, this is only one example, and the present 
invention can still be realized even if more or less areas are 
included. 

[0089] The display processing that the application 506 performs 
involves generating an image to be displayed in the first video area 
30 651 and second video area 652 of the video plane 209, the first still 
area 661 of the still plane 210, and the first OSD area 671 and 
second OSD area 672 of the OSD plane 211; the display 212 
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synthesizes the images generated in these areas and displays the 
synthesized image. 

[0090] FIG. 9 is a conceptual diagram showing an example of the 
display 212 synthesizing the images in the 5 planes and outputting 
5 the synthesized Images. As shown in FIG. 9 (1), an image including 
graphics content 701 Is stored In the first OSD area 671. The 
graphics content 701 Is character Information, and is information 
rendered by a character broadcast application 506 so as to scroll 
from right to left. As shown In FIG. 9 (2), an image including 

10 graphics content 702 is stored in the second OSD area 672. The 
graphics content 702 is character information, and shows the 
current information of a baseball game. This display is updated by 
the application 506 as the baseball game progresses. As shown in 
FIG. 9 (3), an image including video content 703 is stored in the first 

15 video area 651. The video content 703 is formed of a superimposed 
child screen, and displays the video of a certain channel at a reduced 
size to the bottom-left of video content 704, which will be mentioned 
later. For the video content 703, the display position, display size, 
and channel of the video to be reproduced are determined by the 

20 application 506. As shown in FIG. 9 (4), an image Including video 
content 704 is stored in the second video area 652. Video content 
704 is formed of a superimposed main screen, uses approximately 
2/3 of the right side of the screen, and displays the video of a certain 
channel. For the video content 704, the display position, display 

25 size, and channel of the video to be reproduced are determined by 
the application 506. As shown in FIG. 9 (5), an image including still 
content 705 is stored in the first still area 661. Here, the still 
content 705 is a single-color fill that covers the entirety of the 
screen. In the images in each area shown in FIG. 9 (1) through (5), 

30 parts in which graphics content, video content, and still content are 
not placed are transparent. The display 212 superimposes the 
Images shown in FIG. 9 (1) through (5) in order from the bottom, or 
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in other words, the first stili area 661, second video area 652, first 
video area 651, second still area 672, first still area 671, and creates 
a synthesized image. In other words, the first still area 661, 
second video area 652, first video area 651, second still area 672, 
5 and first still area 671 have a vertical positional order, and the 
display 212 understands this vertical order. Here, "superimposing" 
refers to writing the top image onto the bottom image. Note that a 
lower image will appear in the transparent area of an upper image. 
As shown in FIG. 9 (6), the display 212 indicates a synthesized 
10 image in which the images indicated by FIG. 9 (1) through (5) have 
been synthesized. 

[0091] The application 506 can thus implement an effective 
display by synthesizing a plurality of images in this manner. For 
example, the graphics content 701 indicated by FIG. 9 (1) and the 

15 graphics content indicated by FIG. 9 (2) are superimposed. 
Conventionally, the application 506 would attempt to render the 
superimposed graphics content 701 and 702 in the same area of the 
OSD plane. In such a case, the application 506 must perform 
rendering while taking into consideration the overlap of the graphics 

20 content 701 and 702. This causes the rendering processing to slow 
down; for example, the character broadcast of the graphics content 
701 will scroll at a slower speed. However, as mentioned above, in 
the present embodiment, faster rendering processing can be 
realized by the application 506 rendering the two graphics contents 

25 in separate OSD areas and the display 212 performing synthesis 
processing. In addition, the complexity of the application 506 can 
be reduced, as can the work required in developing the application 
506. 

[0092] Furthermore, the same effect can obtained for the video 
30 contents 703 and 704 indicated by FIGS. 9 (3) and (4). The video 
is reproduced by the video decoder 208. For example, 
conventionally, two videos are reproduced simultaneously and in 
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parailei, and the two video contents are superimposed and stored in 
the same area of the video plane. In such a case, the video encoder 
208 must perform exclusion processing for the superimposed parts. 
As a result, the decoding processing slows down, and there is the 
5 possibility that the video cannot be reproduced with smooth 
movement. However, as mentioned above, in the present 
embodiment, faster video rendering processing can be realized by 
the video decoder 208 storing the two video contents In separate 
video areas and the display 212 performing synthesis processing. 

10 [0093] Here, the functions of the OSD processing unit 505h, video 
processing unit 5051, and still processing unit SOSj, which are used 
to implement synthesis of the images indicated in FIG. 9, shall be 
described. In the DVB-MHP specifications, each area in the planes 
is expressed as an instance of a class. One area of the OSD plane 

15 211 is expressed as an instance of the HGraphicsDevice class; one 
area of the video plane 209 is expressed as an instance of the 
HVideoDevice class; and one area of the still plane 210 is expressed 
as an instance of the HBackgroundDevice class. The application 
506 can acquire these instances from methods provided by the 

20 HScreen class. The getHGraphicsDevices method stores, in an 
array, the same number of instances of the HGraphlcs Device as 
there are areas held by the OSD plane 211, and returns this array; 
the getHVideoDevices method stores, in an array, the same number 
of instances of the HVideoDevice as there are areas held by the 

25 video plane 209, and returns this array; and the 
getHBackgroundDevices method stores, in an array, the same 
number of instances of the HBackgroundDevice as there are areas 
held by the still plane 210, and returns this array. In the present 
invention, the Z-order management unit 601 of the OSD processing 

30 unit 505h stores HGraphicsDevice instances in the array returned by 
the getHGraphicsDevices method in accordance with the vertical 
order. Here, the HGraphicsDevice instances corresponding to OSD 
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areas are stored in the array in order from the OSD area located 
higher in the vertical order. In the case where the terminal 
apparatus 200 is configured as shown in FIGS. 8 and 9, the Z-order 
management unit 601 of the OSD processing unit 505h stores the 
5 HGraphlcsDevice instance of the first OSD area 671, which is 
positioned higher In the vertical order, in the first element of the 
array, and stores the HGraphlcsDevice instance of the second OSD 
area 672, which Is positioned lower in the vertical order, in the 
second element of the array. Similarly, the Z-order management 

10 unit 611 of the video processing unit 5051 also stores the 
HVideoDevice instances in the array returned by the 
getHVideoDevices method in accordance with the vertical order. 
Also, the Z-order management unit 621 of the still processing unit 
SOSj stores the HBackgroundDevice instances In the array returned 

15 by the getHBackgroundDevices method in accordance with the 
vertical order. However, in FIG. 8, the still plane 210 has only one 
area. Therefore, the Z-order management unit 621 of the still 
processing unit SOSj simply stores the HBackgroundDevice instance 
corresponding to the first still area 661 in the array. 

20 [0094] In short, the roles of the Z-order management unit 601, 
Z-order management unit 611, and Z-order management unit 621 
are as follows: the Z-order management unit 601, Z-order 
management unit 611, and Z-order management unit 621 each 
manage a set of the areas held by the OSD plane 211, video plane 

25 209, and still plane 210, the vertical order thereof, and the instance 
corresponding to each area, as a management table. When the 
getHGraphicsDevice method, getHVideoDevice method, and 
getHBackgroundDevice method are called, the Z-order management 
unit 601, Z-order management unit 611, and Z-order management 

30 unit 621 store the HGraphlcsDevice instance, HVideoDevice instance, 
and HBackgroundDevice instance in the array based on the vertical 
order Information within the management table, and return the 
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array. 

[0095] FIGS. lOA, lOB, and IOC are diagrams showing examples 
of the management tables respectively managed by the Z-order 
management unit 601, Z-order management unit 611, and Z-order 
5 management unit 621. 

[0096] FIG. lOA shows an example of the management table 
managed by the Z-order management unit 601 of the OSD 
processing unit 505h. Column 801 holds an address for an area of 
the OSD plane 211. Column 802 holds information indicating the 

10 vertical order of the area indicated in column 801. Here, numbers 
are stored in column 802, with the numbers being assigned in order 
from the top of the vertical order, such as "1", "2", and so on. Note 
that this vertical order refers to the vertical order within the OSD 
plane 211. The vertical order of the OSD plane 211, video plane 

15 209, and still plane 210 is fixed, with the OSD plane 211 at the top, 
the video plane 209 next, followed by the still plane 210. Column 
803 stores the HGraphicsDevice instance which corresponds to the 
area indicated in column 801. This instance is generated and held 
when the terminal apparatus 200 is turned on. Information 

20 corresponding to the first OSD area 671 of the OSD plane 211 is 
stored in row 811; information indicating that the first OSD area 671 
is highest in the vertical order and a corresponding 
"HGraphicsDeviceA" instance are stored in this row. Here, the 
letter "A" is simply a letter attached to identify the instance, and has 

25 no particular meaning. Information corresponding to the second 
OSD area 672 of the OSD plane 211 is stored in row 812; information 
Indicating that the second OSD area 672 is second-highest in the 
vertical order and a corresponding '"HGraphicsDevlceB" instance are 
stored in this row. As before, the letter "B" is simply a letter 

30 attached to identify the instance, and has no particular meaning. 
[0097] FIG. lOB shows an example of the management table 
managed by the Z-order management unit 611 of the OSD 
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processing unit 5051. Column 821 holds an address for an area of 
the OSD plane 209. Column 822 holds information indicating the 
vertical order of the area indicated in column 821. Here, numbers 
are stored in column 822, with the numbers being assigned in order 
5 from the top of the vertical order, such as "1", "2" and so on. Note 
that this vertical order refers to the vertical order within the OSD 
plane 209. Column 823 stores the HVideoDevice Instance which 
corresponds to the area indicated in column 821. This instance is 
generated and held when the terminal apparatus 200 is turned on. 

10 Information corresponding to the first video area 651 of the video 
plane 209 is stored in row 831; information indicating that the first 
video area 651 is highest in the vertical order and a corresponding 
"HVIdeoDeviceA" instance are stored in this row. Here, the letter 
is simply a letter attached to identify the instance, and has no 

15 particular meaning. Information corresponding to the second video 
area 652 of the video plane 209 is stored in row 832; information 
indicating that the second video area 652 is second-highest in the 
vertical order and a corresponding "HVideoDeviceB" instance are 
stored in this row. Again, the letter "B" is simply a letter attached 

20 to identify the instance, and has no particular meaning. 

[0098] FIG. IOC shows an example of the management table 
managed by the Z-order management unit 621 of the still processing 
unit 505j. Column 841 holds an address for an area of the still 
plane 210. Column 842 holds information indicating the vertical 

25 order of the area indicated in column 841. Here, numbers are 
stored in column 842, with the numbers being assigned in order 
from the top of the vertical order, such as "1", "2", and so on. Note 
that this vertical order refers to the vertical order within the still 
plane 210. Column 843 stores the HBackgroundDevice instance 

30 which corresponds to the area indicated in column 841. This 
instance is generated and held when the terminal apparatus 200 is 
turned on. Information corresponding to the first still area 661 of 
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the still plane 210 Is stored In row 851; information indicating that 
the first still area 661 is highest in the vertical order and a 
corresponding "HBackgroundDeviceA" instance are stored in this 
row. As before, the letter "A" is simply a letter attached to identify 
5 the instance, and has no particular meaning. 

[0099] FIG. 11 is a flowchart showing an operation of the Z-order 
management unit 601 of the OSD processing unit 505h. As shown 
in FIG. 11, when the application 506 calls the getHGraphicsDevice 
method, the 2-order management unit 601 accepts a request to 

10 acquire the HGraphicsDevice instance (Step S901). The 2-order 
management unit 601 prepares an array with a number of elements 
equal to the number of areas included in the OSD plane 211 (Step 
S902). When the terminal apparatus 200 is configured as shown in 
FIG. 8, the Z-order management unit 601 prepares an array with "2" 

15 array elements. In the case where the Java language is used, the 
Z-order management unit 601 writes 

''HGraphicsDevice[]array=newHGraphicsDevice[2]". Next, the 
Z-order management unit 601 sets a variable N to an initial value of 
''1" (Step S903). Referring to the management table, the Z-order 

20 management unit 601 searches for the area Nth in vertical order, 
and acquires the corresponding HGraphicsDevice instance (Step 
S904). For example, when the management table is configured as 
shown in FIG. lOA, if N = l, the first OSD area 671 in row 811 is first 
in the vertical order, and therefore the corresponding 

25 "HGraphicsDeviceA" is acquired. Next, the Z-order management 
unit 601 stores the acquired HGraphicsDevice instance in the Nth 
array element (Step S905). When the acquired instance is 
"HGraphtcsDeviceA", and N = l, "HGraphicsDeviceA" is stored in the 
first array element. In the case where the Java language is used, 

30 the Z-order management unit 601 writes 
"array[0] = HGraphicsDevice_A". Here, the array element number is 
''0" because the array script starts at "0". HGraphicsDevice_A is a 
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variable that indicates "HGraphicsDeviceA". Next, the Z-order 
management unit 601 adds 1 to the variable N (Step S906). When 
the value of the variable N is less than or equal to the number of 
areas in the OSD plane 211 (NO of Step S907), the Z-order 
5 management unit 601 repeats the processing from Step S904. 
When the value of the variable N is greater than the number of areas 
in the OSD plane 211 (YES of Step S907), the Z-order management 
unit 601 returns the array to the application 506 (Step S908). For 
example, when the management table is configured as shown in FIG. 
10 lOA, an array with a length of 2, in which "HGraphicsDeviceA" is 
stored in the first array element and ''HGraphicsDeviceB" Is stored in 
the second array element, Is returned. 

[0100] FIG. 12 is a flowchart showing an operation of the Z-order 
management unit 611 of the video processing unit 505i. As shown 

15 in FIG. 12, when the application 506 calls the getHVideoDevice 
method, the Z-order management unit 611 accepts a request to 
acquire the HVideoDevice instance (Step SlOOl). The Z-order 
management unit 611 prepares an array with a number of elements 
equal to the number of areas included in the video plane 209 (Step 

20 S1002). When the terminal apparatus 200 is configured as shown 
in FIG. 8, the Z-order management unit 611 prepares an array with 
"2" array elements. In the case where the Java language is used, 
the Z-order management unit 611 writes 
"H\/ideoDevice[]array = newHVIdeoDevice[2]". Next, the Z-order 

25 management unit 611 sets a variable N to an initial value of "1" 
(Step S1003). Referring to the management table, the Z-order 
management unit 611 searches for the Nth area in vertical order, 
and acquires the corresponding HVideoDevice instance (Step 
S1004). For example, when the management table is configured as 

30 shown in FIG. lOB, if N = l, the first video area 651 in row 831 is first 
in the vertical order, and therefore the corresponding 
"HVideoDeviceA" is acquired. Next, the Z-order management unit 
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611 stores the acquired HVideoDevice instance in the Nth array 
element (Step S1005). When the acquired instance is 
"HVideoDeviceA", and iM = l, "HVideoDeviceA" is stored in the first 
array element. In the case of using the Java language, the Z-order 
5 management unit 611 writes "array[0] = HV!deoDevtce_A". Here, 
the array element number Is "0" because the array script starts at 
"0". HVideoDevlce_A is a variable that indicates "HVideoDeviceA". 
Next, the Z-order management unit 611 adds 1 to the variable N 
(Step S1006). When the value of the variable N is less than or 

10 equal to the number of areas in the video plane 209 (NO of Step 
S1007), the Z-order management unit 611 repeats the processing 
from Step S1004. When the value of the variable N is greater than 
the number of areas in the video plane 209 (YES of Step S1007), the 
Z-order management unit 611 returns the array to the application 

15 506 (Step S1008). For example, when the management table is 
configured as shown in FIG. lOB, an array with a length of 2, in 
which "HVideoDeviceA" is stored in the first array element and 
"HVideoDeviceB" is stored in the second array element, is returned. 
[0101] FIG. 13 is a flowchart showing an operation of the Z-order 

20 management unit 621 of the still processing unit 505j. As shown In 
FIG. 13, when the application 506 calls the getHBackgroundDevice 
method, the Z-order management unit 621 accepts a request to 
acquire the HBackgroundDevice instance (Step SllOl). The 
Z-order management unit 621 prepares an array with a number of 

25 elements equal to the number of areas included in the still plane 210 
(Step S1102). When the terminal apparatus 200 is configured as 
shown in FIG. 8, the Z-order management unit 621 prepares an 
array with "1" array element. In the case where the Java language 
is used, the Z-order management unit 621 writes 

30 "HBackgroundDevice[]array = newHBackgroundDevice[l]". Next, 
the Z-order management unit 621 sets a variable N to an initial 
value of "1" (Step S1103). Referring to the management table, the 
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Z-order management unit 621 searches for the Nth area in vertical 
order, and acquires the corresponding HBackgroundDevice Instance 
(Step S1104). For example, when the management table is 
configured as shown in FIG. IOC, if !\l = l, the first still area 661 in 
5 row 851 is first in the vertical order, and therefore the corresponding 
"HBackgroundDevlceA" is acquired. Next, the Z-order 
management unit 621 stores the acquired HBackgroundDevice 
instance in the Nth array element (Step S1105). When the 
acquired instance is "HBackgroundDeviceA", and N = l, 

10 "HBackgroundDeviceA" is stored in the first array element. In the 
case of using the Java language, the Z-order management unit 621 
writes "array[0] = HBackgroundDevice_A". Here, the array element 
number is "0" because the array script starts at "0". 
HBackgroundDevice_A is a variable that indicates 

15 "HBackgroundDeviceA". Next, the Z-order management unit 621 
adds 1 to the variable N (Step S1106). When the value of the 
variable N is less than or equal to the number of areas in the still 
plane 210 (NO of Step S1107), the Z-order management unit 621 
repeats the processing from Step S1104. When the value of the 

20 variable N is greater than the number of areas In the still plane 210 
(YES of Step S1107), the Z-order management unit 621 returns the 
array to the application 506 (Step S1108). For example, when the 
management table is configured as shown in FIG. IOC, an array with 
a length of 1, in which '^HBackgroundDeviceA" is stored in the array 

25 element, is returned. 

[0102] The storage sequence for the elements of the array 
returned by the getHGraphlcsDevices method corresponds to the 
vertical order of the areas in the OSD plane 211; the storage 
sequence for the elements of the array returned by the 

30 getHVideoDevices method corresponds to the vertical order of the 
areas in the video plane 209; and the storage sequence for the 
elements of the array returned by the getHBackgroundDevices 
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method corresponds to the vertical order of the areas in the OSD 
plane 210. Therefore, the application 506 can obtain the 
HGraphicsDevice instance, the HVideoDevlce instance, and the 
HBackgroundDevtce instance corresponding to the layers 
5 appropriate for use in displaying. Hereafter, a process through 
which the application 506 performs rendering processing based on 
these obtained instances shall be briefly described. 
[0103] When rendering into the OSD plane 211, the application 
506 acquires an HScene instance by passing the HGraphicsDevice 

10 instance as an argument to the HSceneFactory class 
getFullScreenScene method prescribed in the org.havi.ul package. 
The HScene instance obtained at this time is a base window created 
in an area of the OSD plane 211 that corresponds to the 
HGraphicsDevice Instance provided by the argument. The HScene 

15 Instance is an instance of the HScene class, which is a successor to 
the java.awt package Container class; the application 506 can 
perform rendering using the function of the AWT 505f, which is in the 
library 505. The function of the AWT 505f is equivalent to the 
functions of the java.awt package and subpackages thereof; this 

20 rendering function is publicly-known technology, and thus 
descriptions shall be omitted. Here, an example of this rendering 
shall be introduced. 

[0104] FIG. 14 is a diagram showing an example of program code 
of the application 506. Here, the terminal apparatus is configured 

25 as shown in FIG. 8, and the management table is configured as 
shown in FIG. lOA. In lines 1 and 2 of FIG. 14, the application 506 
obtains an array device that stores the two HGraphicsDevice 
Instances. The application 506 acquires the HSceneFactory class 
instance in line 3 of FIG. 14; after that, in line 4 of FIG. 14, the 

30 application 506 uses the HGraphicsDevice instance stored in the 
variable device[0] and obtains the HScene instance that 
corresponds to the first OSD area 671 of the OSD plane 211, which 



-35 - 



is located higher In the vertical order. Next, in line 5 of FIG. 14, the 
application 506 completes preparation for rendering by acquiring 
the Graphics instance from the HScene instance, and in line 6 of FIG. 
14/ sets the color. Here, the application 506 sets the color to black. 
5 In addition, in line 7 of FIG. 14, the application 506 writes the 
character string "Graphics" at coordinates (30, 30) of the first OSD 
area 671. 

[0105] Furthermore, In line 9 of FIG. 14, the application 506 uses 
the HGraphtcsDevice Instance stored in the variable device[l] and 

10 obtains the HScene instance that corresponds to the second OSD 
area 672 of the OSD plane 211, which is located tower in the vertical 
order. In line 10 of FIG. 14, the application 506 completes 
preparation for rendering by acquiring the Graphics instance from 
the HScene instance, and in line 11 of FIG. 14, sets the color. Here, 

15 the application 506 sets the color to white. In addition, in line 12 of 
FIG. 14, the application renders a rectangle filled with white in the 
second OSD area 672. 

[0106] FIG. 15 is a diagram showing the results of the rendering 
performed by the application indicated in FIG. 14. As shown in FIG. 

20 15 (1), the character string "Graphics" is rendered at coordinates 
(30, 30) in the first OSD area 671. As shown in FIG. 15 (2), the 
second OSD area 672 is filled with white. As shown in FIG. 15 (3), 
the display 212 shows the result of synthesis. As the second OSD 
area 672 is filled with white, details shown in the video plane 209 

25 and still plane 210 below are hidden. In this result of synthesis, the 
image in the second OSD area 672 is overwritten by the Image in the 
first OSD area 671. 

[0107] When reproducing video (rendering video) in the video 
plane 209, the application 506 calls the getVideoController method, 
30 which is prepared by the HVideoDevice instance, and acquires the 
Player instance. The Player instance provides a function for 
reproducing video and sound provided by the JMF 505e of the library 
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505. By calling various methods prepared by the Player Instance, 
the application 506 can specify the video and audio to be reproduced, 
the position the reproduced video is displayed on the screen, and the 
size the video is displayed at. The functions provided by the 3MF 
5 505e are publicly-known technology, and thus detailed descriptions 
shall be omitted. A method In which the application 506 obtains the 
Player instances corresponding to each area of the video plane 209 
shall be introduced here. 

[0108] FIG. 16 is a diagram showing an example of program code 
10 of the application 506. Here, the terminal apparatus is configured 
as shown in FIG. 8, and the management table Is configured as 
shown in FIG. lOB. In lines 1 and 2 of FIG. 16, the application 506 
obtains an array device that stores the two HVideoDevice instances. 
In line 3 of FIG. 16, the application 506 calls the getVideoController 
15 method of the HVideoDevice instance stored in the variable 
device[0], thereby obtaining the Player instance corresponding to 
the first video area 651 of the video plane 209, which is positioned 
higher in the vertical order. In addition, in line 5 of FIG. 16, the 
application 506 calls the getVideoController method of the 
20 HVideoDevice instance stored in the variable device[l], thereby 
obtaining the Player instance corresponding to the second video 
area 652 of the video plane 209, which Is positioned lower in the 
vertical order. 

[0109] When rendering in the still plane 210, the application 506 
25 calls the method prepared by the HBackgroundDevice instance, and 
obtains the HBackgroundConfiguration instance. The 
HBackgroundConflguration instance provides a setColor method for 
filling an area in the still plane 210 with a single color. 
[0110] FIG. 17 is a diagram showing an example of program code 
30 of an application 506. Here, the terminal apparatus is configured 
as shown in FIG. 8, and the management table is configured as 
shown in FIG. IOC. In lines 1 and 2 of FIG. 17, the application 506 
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obtains an array device that stores the one HBackgroundDevice 
instance. In lines 3 and 4 of FIG. 17, the application 506 calls the 
getCurrentConfiguration method of the HBackgroundDevice 
instance stored in the variable device[0], and obtains the 
5 HBackgroundConfiguration instance. In addition, in line 5 of FIG. 
17, the application 506 calls the setColor method of the 
HBackgroundlnstance. Here, by passing "blue" in the argument, 
the application 506 fills the first still area 661 of the still plane 210 
with blue. 

10 [0111] On the other hand, the Z-order changing unit 602 provides 
a function for changing the vertical order of the areas managed by 
the Z-order management unit 601, the Z-order changing unit 612 
provides a function for changing the vertical order of the areas 
managed by the Z-order management unit 611, and the Z-order 

15 changing unit 622 provides a function for changing the vertical order 
of the areas managed by the Z-order management unit 621. For 
example, the Z-order changing unit 602 of the OSD processing unit 
505h provides a setHGraphicsDeviceZOrder method to the 
HScreen class. This method receives an HGraphicsDevlce instance 

20 as a first argument, and receives a numerical value indicating the 
vertical position as a second argument. The numerical value 
ranges from 1 to the number of areas in the OSD plane 211. 
[0112] FIG. 18 is a flowchart showing an operation of the Z-order 
changing unit 602. The Z-order changing unit 602 receives a 

25 HGraphicsDevlce instance and a change value indicating the vertical 
position to be changed (Step S1601). Referring to the 
management table managed by the Z-order management unit 601, 
the Z-order changing unit 602 acquires a setting value (associated 
setting value) that corresponds to the received HGraphicsDevlce 

30 instance (Step S1602). Note that the "setting value" is a numerical 
value stored in a management table in association with an instance, 
and the "associated setting value" is a setting value associated with 
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the HGraphicsDevice received by the Z-order changing unit 602. At 
this time, the Z-order changing unit 602 nnay cause the associated 
setting value to be stored in the primary storage unit 214. Next, 
the Z-order changing unit 602 finds, from the management table, a 
5 setting value identical to the received change value, which indicates 
the vertical position, and overwrites that setting value with the 
associated setting value (Step S1603). Last, the Z-order changing 
unit 602 overwrites the associated setting value corresponding to 
the received HGraphicsDevice instance with the received change 

10 value (Step S1604). 

[0113] To be more specific, the HGraphicsDevice instance 
received from the application 506 Is the "HGraphicsDeviceB", the 
received change value is "1", and the management table is 
configured as shown in FIG. lOA. 

15 [0114] FIG. 19 is a diagram showing details of a management 
table changed as in the abovementioned situation. In this case, the 
Z-order changing unit 602 refers to the management table shown in 
FIG. lOA, and acquires the associated setting value "2" that 
corresponds to "HGraphicsDevlceB" from row 812 of the 

20 management table. Next, when the Z-order changing unit 602 
searches the management table for a setting value identical to the 
change value "1", which indicates the vertical position, it finds this 
setting value in row 811. Here, as shown in FIG. 19 (1), the 
Z-order changing unit 602 rewrites the setting value "1" in line 811 

25 with the acquired associated setting value of "2". Lastly, as shown 
In FIG. 19 (2), the Z-order changing unit 602 overwrites the 
associated setting value corresponding to the "HGraphlcsDevlceB" 
in row 812 with the received change value of "1". 
[0115] Similarly, the Z-order changing unit 612 of the video 

30 processing unit 5051 has a function for changing the management 
table of the Z-order management table 611, and the Z-order 
changing unit 622 of the still processing unit 505j has a function for 
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changing the management table of the Z-order management table 
621. 

[0116] By providing the Z-order changing unit 602, Z-order 
changing unit 612, and Z-order changing unit 622, the application 
5 506 can easily change the vertical order of two images. 

[01173 FIGS. 20A and 20B are diagrams for describing a change in 
the vertical order of two images. As shown in FIG. 20A, an image 
including graphics content 1801 is stored in the first OSD area 671. 
This graphics content 1801 is a window in which various information 

10 is displayed. On the other hand, an image including graphics 
content 1802 is stored in the second OSD area 672. This graphics 
content 1802 is also a window in which various information is 
displayed. The first OSD area 671 is above the second OSD area 
672 in the vertical order. Therefore, by synthesizing the images in 

15 the first OSD area 671 and the second OSD area 672, the display 
212 displays the graphics content 1801 and 1802 so that the window 
of the graphics content 1801 partially overlaps the window of the 
graphics content 1802. Here, when the window of the graphics 
content 1802 is to be displayed on top, the application 506 uses the 

20 Z-order changing unit 602 to move the second OSD area 672 to the 
top, as shown in FIG. 20B. As a result, the display 212 displays the 
graphics content 1801 and 1802 so that the window of the graphics 
content 1802 partially overlaps the window of the graphics content 
1801. In other words, the vertical order of the two areas (images) 

25 is changed. Here, at the time of synthesis, the display 212 
determines the order of synthesis by referring to the management 
tables held by the Z-order management unit 601, the Z-order 
management unit 611, and the Z-order management unit 621. 
[0118] Note that in this embodiment, changing the vertical order 

30 of areas (images) is realized through a method of interchanging the 
two areas (images). 

[0119] FIG. 21 is a diagram showing a method for changing the 
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vertical order of areas (images). 

For example, as shown In FIG. 21 (1), there are five areas (an 
area 1901 to an area 1905); the application 506 is to position the 
area 1902 fourth from the top. In this case, the application 506 
5 Interchanges the area 1902 with an area 1904, as shown in FIG. 21 
(2). However, the vertical order of areas can be changed through 
another method. 

[0120] FIG. 22 Is a diagram showing another method for changing 
the vertical order of areas. 
10 For example, when the application 506 is to position the area 

1902 shown In FIG. 21 (1) fourth from the top, the application 506 
inserts the area 1902 below the area 1904. 

[0121] In the present embodiment, a method called 
setHGraphicsDevlceZOrder Is prepared as the function for providing 

15 the Z-order changing unit 602, Z-order changing unit 612, and 
Z-order changing unit 622; however, a method of a different name 
may be prepared as long as the function is identical. Also, in the 
present embodiment, the setHGraphicsDeviceZOrder method, which 
takes two arguments. Is given as an example, but a different API 

20 may be provided. For example, a procedure that moves the 
HGraphtcsDevice provided by the argument to the top position 
(setTopHGraphicsDevice), a method that moves the 
HGraphicsDevice to the bottom position 

(setBottomHGraphicsDevice), and so on may be used. The 

25 setTopHGraphicsDevice is implemented so as to internally provide a 
vertical position value of "1" to the setHGraphicsDeviceZOrder 
method. The setBottomHGraphicsDevice is implemented so as to 
Internally provide a vertical position value equal to the number of 
areas to the setHGraphicsDeviceZOrder method. 

30 [0122] Furthermore, in the present embodiment, specifying 
instances corresponding to two areas as an argument and 
interchanging the vertical position of those two areas can be 
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implemented as a method for changing the vertical position of each 
area in the OSD plane 211, the video plane 209, and the still plane 
210. For example, an exchangeHGraphicsDeviceZOrder method is 
prepared in the HScreen class. This method receives two 
5 HGraphlcsDevice instances as arguments. Referring to the 
management table, the vertical positions of the HGraphlcsDevices 
may be acquired, interchanged, and stored within the method. For 
example, in the case where the management table is configured as 
shown in FIG. lOA, when the two HGraphicsDevice instances 

10 "HGraphicsDeviceA" and "HGraphlcsDeviceB" are provided as 
arguments, and the vertical position value "1" of 
"HGraphicsDeviceA" and the vertical position value "2" of 
"HGraphicsDeviceB" are taken; then, "2", which is the vertical 
position value of "HGraphlcsDeviceB", is written as the vertical 

15 position value of "HGraphicsDeviceA", and "1", which is the vertical 
position value of "HGraphicsDeviceA", is written as the vertical 
position value of "HGraphlcsDeviceB". As a result, the 
management table changes to the state shown in FIG. 19 (2). 
[0123] In addition, in the present embodiment, the Z-order 

20 management unit 601, Z-order management unit 611, and Z-order 
management unit 621 use an order of storing instances in the array 
to notify the application 506 of the vertical order of each area in the 
OSD plane 211, video plane 209, and still pane 210 that correspond 
to the instances. However, this can be implemented in a different 

25 manner. For example, the vertical order can be obtained by 
providing a method that acquires the vertical order in the instances, 
and the application 506 calling that method. To be more specific, a 
getZOrder method is provided in the HGraphicsDevice Instance, the 
HVideoDevice instance, and the HBackgroundDevice instance. This 

30 method returns a numerical value that represents a vertical position 
corresponding to each instance. For example, assuming the 
management table is configured as shown in FIG. lOA, the 
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getZOrder method of the HGraphicsDevice instance 
"HGraphicsDeviceA" refers to row 811 of FIG. lOA and returns a 
value of "1". 

[0124] FIG. 23 is a schematic diagram showing a relationship 
5 between the management table and the HGraphicsDevice instances 
for implementing the getZOrder method. Column 803 holds a 
pointer to an HGraphicsDevice instance. Row 811 holds a pointer 
2102 to an HGraphicsDevice instance "HGraphicsDeviceA" 2101, and 
row 812 holds a pointer 2112 to an HGraphicsDevice Instance 

10 "HGraphicsDeviceB" 2111. Also, the HGraphicsDevice instances 
have pointers to their rows in the corresponding management tables. 
The HGraphicsDevice instance "HGraphicsDeviceA" 2101 has a 
pointer 2103 to row 811, and the HGraphicsDevice instance 
"HGraphicsDeviceB" 2111 has a pointer 2113 to row 812. When the 

15 getZOrder method of an HGraphicsDevice instance is called, the 
HGraphicsDevice instance can fetch the value indicating the 
corresponding vertical position by following the pointer, and return 
the value to the application 506. 

[0125] Furthermore, as a different procedure, a 

20 getHGraphicsZOrder method, a getHVideoZOrder method, and a 
getHBackgroundZOrder method may be provided In the HScreen 
class. Each method can receive the HGraphicsDevice instance, the 
HVideoDevice instance, and the HBackgroundDevice instance as 
arguments. Each method respectively refers to the management 
25 tables held by the Z-order management unit 601, the Z-order 
management unit 611, and the Z-order management unit 621, and 
returns a vertical position value corresponding to the received 
instance. Through this, by calling the getHGraphicsZOrder method, 
the getHVideoZOrder method, and the getHBackgroundZOrder 
30 method, the application 506 can know the vertical positions of the 
areas that correspond to each instance. 

[0126] Note that in the present embodiment, the vertical order 
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has been described as starting with the number "1" and proceeding 
in the order of "1", "2" and so on, from top to bottom; however, the 
vertical order may start with the number "0" and proceed in the 
order of "0", "1" "2", and so on. Also, when the number of areas is 
5 N, the vertical order may proceed in the order of "N", "N-1", and so 
on, from top to bottom. Or, the instances that represent areas may 
be managed in a list structure, with the order stored in the list 
structure associated with the vertical order and managed. In 
addition, In the present embodiment, the management tables shown 

10 in FIGS. lOA through IOC are used for managing the vertical order, 
but the management table may be in any format as long as the areas, 
information indicating the vertical order, and relation to the 
instances are stored and are each searchable; a format that utilizes 
a list structure may be used. 

15 [0127] In the present embodiment, three types of planes have 
been described; however, the number of planes does not have to be 
three (for example, there is no still plane), and another number of 
planes, such as four or five, may be used, as long as the vertical 
order between each plane Is set. 

20 

[0128] (Second Embodiment) 

In the first embodiment, changing the vertical order of the 
areas within the OSD plane 211 only changed the order within the 
OSD plane; changes across planes is not possible. However, In the 

25 second embodiment, changes across planes is possible. 

[0129] FIG. 24 is a conceptual diagram showing a relationship 
between hardware components and software components related to 
the display function In the terminal apparatus 200 of the present 
embodiment. In FIG. 24, components given the same numbers as 

30 in FIG. 8 represent the same components shown in FIG. 8 in the first 
embodiment, and thus detailed description shall be omitted. As 
shown in FIG. 24, the OSD processing unit 505h, the video 
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processing unit 505i, the stil! processing unit 505j do not eacli have 
a Z-order management unit 601, a Z-order changing unit 602, a 
Z-order management unit 611, a Z-order changing unit 612, a 
Z-order management unit 621, and a Z-order changing unit 622. 
5 Instead, the display processing device includes a common 
processing unit 2200, which in turn has a Z-order management unit 
2201 and a Z-order changing unit 2202. The Z-order management 
unit 2201 manages, through a management table, areas of the OSD 
plane 211, the video plane 209, and the still plane 210; information 
10 Indicating the vertical order of the areas; and instances 
corresponding to each area. 

[0130] FIG. 25 Is a diagram showing an example of a 
management table according to the present embodiment. Column 
2301 holds addresses to the areas in the OSD plane 211, the video 

15 plane 209, and the still plane 210. Column 2302 holds information 
indicating the vertical order of the area indicated in column 2301. 
Here, numerical values are stored in column 2302, with the numbers 
being assigned in order from the top of the vertical order, such as"l", 
"2" and so on. Note that this vertical order is a vertical order in 

20 which the OSD plane 211, the video plane 209, and the still plane 
210 are mixed together. Column 2303 holds the HGraphicsDevlce 
instance, the HVideoDevice Instance, and the HBackgroundDevice 
Instance corresponding to the area shown in column 2301. This 
instance is generated and held when the terminal apparatus 200 is 

25 turned on. Information corresponding to the first OSD area 671 of 
the OSD plane 211 is stored in row 2311; specifically, information 
indicating that the first OSD area 671 is highest in the vertical order 
and a corresponding "'HGraphicsDeviceA" instance are stored in this 
row. Here, the letter "A" is simply a letter attached to identify the 

30 instance, and has no particular meaning. 

[0131] Information corresponding to the first video area 651 of 
the video plane 209 is stored in row 2312; specifically, information 
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indicating that the first video area 651 is second from the top in the 
vertical order and a corresponding "HVideoDeviceA" instance are 
stored in this row. Again, the letter "A" is simply a letter attached 
to identify the instance, and has no particular meaning. 
5 [0132] Information corresponding to the second OSD area 672 of 
the OSD piane 211 is stored in row 2313; specificaily, information 
indicating that the second OSD area 672 Is third from the top in the 
vertical order and a corresponding "HGraphicsDeviceB" instance are 
stored in this row. Here, the letter "B" is simply a letter attached to 

10 identify the instance, and has no particular meaning. 

[0133] Information corresponding to the second video area 652 of 
the video plane 209 is stored in row 2314; specifically, information 
indicating that the second video area 652 is fourth from the top in 
the vertical order and a corresponding "HVideoDeviceB" instance 

15 are stored in this row. Again, the letter "B" is simply a letter 
attached to identify the instance, and has no particular meaning. 
[0134] Information corresponding to the first still area 661 of the 
still plane 210 is stored in row 2315; specificaiiy, information 
indicating that the first still area 661 is fifth from the top in the 

20 vertical order and a corresponding "HBackgroundDeviceA" instance 
are stored in this row. As before, the letter "A" is simply a letter 
attached to identify the instance, and has no particular meaning. 
[0135] When synthesizing and outputting the images shown in 
the areas of the planes, the display 212 refers to the management 

25 table managed by the Z-order management unit 2201, and performs 
synthesis based on the vertical order. When the management table 
is configured as shown in FIG. 25, the display 212 superimposes the 
images shown in each area in order from the bottom, or in other 
words, the first stilt area 661, the second video area 652, the second 

30 OSD area 672, the first video area 651, and the first OSD area 671, 
and synthesizes the images. 

[0136] A method that acquires the vertical order provides each of 



-46- 



the abovementioned instances so that the application 506 can know 
the vertical position of each area. The application 506 can find the 
vertical order by calling this method. To be more specific, a 
getZOrder method is provided in the HGraphicsDevice instance, the 
5 HVIdeoDevice instance, and the HBac!<groundDevice instance. This 
method returns a numerical value that indicates a vertical position 
corresponding to each instance. For example, when the 
management table is configured as shown in FIG. 25, the getZOrder 
method of the HGraphicsDevice instance "HGraphicsDeviceB" refers 

10 to row 2313 of FIG. 25 and returns a value of "3". Note that the 
management table of the present embodiment may be configured in 
the same format as the management table shown in FIG. 23 in the 
first embodiment. In other words, the getZOrder method Is 
implemented in such a management table, and thus each area and 

15 each instance in the management table have mutually referential 
relationships. 

[0137] The Z-order changing unit 2202 provides a function for 
changing the vertical order of the areas managed by the Z-order 
management unit 2201. For example, the Z-order changing unit 

20 2 2 02 provides a setDeviceZOrder method in the HScreen class. 
This method accepts an instance as a first argument, and accepts a 
numerical value indicating the vertical position as a second 
argument. This numerical value ranges from 1 to the total number 
of areas held by the OSD plane 211, the video plane 209, and the 

25 still plane 210. The operation of the Z-order changing unit 2202 is 
basically identical to that of the Z-order changing unit 602, the 
Z-order changing unit 612, and the Z-order changing unit 622 of the 
first embodiment. The points in which the operation of the Z-order 
changing unit 2202 differs from that of the Z-order changing unit 

30 602 of the first embodiment are that the corresponding 
management table is not the management table shown in FIG. lOA, 
but the management table shown in FIG. 25, and that the Z-order 
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changing unit 2202 handles three types of instances. The manner 
of changing the vertical order also includes exchanging two areas, 
moving one area and then shifting the other areas vertlcaily, and so 
on, as described in the first embodiment. Furthermore, a method 
5 that changes the area corresponding to an instance to the highest 
position or the lowest position may be provided, as described in the 
first embodiment. 

Industrial Applicability 
10 [0138] A display processing device according to the present 
invention has the advantageous effect of being able to improve 
graphics display performance, and can be applied as a display 
processing device included in Information devices such as personal 
computers, cellular phones, and so on. 
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